fix(workspace): name a workspace by its resolved path - #1798

All committers have signed the CLA.

Hey, thanks for the PR. Could you sign the CLA when you get a chance so we can review it?

Hey, thanks for the PR. Could you sign the CLA when you get a chance so we can review it?

done

Thanks for the thorough review, and for taking the time to run the repros at this head.

All three points are confirmed as real gaps in my patch:

1. Local chat hashing the unresolved PWD alias while the daemon listens on the resolved key - agreed, host lookup, dialing and spawning need to share one resolved workspace.
2. The default HOME path skipping the canonicalization entirely - agreed, engineWorkspace("") needs to go through the same resolution.
3. The five macOS test failures and missing coverage - I will normalize the fixtures and add symlink regressions for local host startup, default HOME and typed /project.

Working on the fixes now; I will push as incremental commits and follow up here with the new SHA once all three points are addressed.

All three points are addressed at d26cae9, pushed as three incremental commits on top of the dev merge.

1. Local chat hashing the alias. The split is gone at the identity layer rather than at any entry point: every host question in internal/enginehost - lookup, dial, spawn, lock, status, stop - funnels through one place, and that place now resolves the spelling before it hashes. A surface dialing through a symlink and a daemon named by the resolved path can no longer build two host directories. Regression: a host standing at the folder answers a dial that arrives through the link (cmd/codeaf), and the two spellings get one socket and one lock (internal/enginehost).

2. The default home. engineWorkspace("") walks the same resolution a typed home does now, so omitting --workspace and naming the same home cannot key two hosts. Regression covers exactly that pair.

3. The five macOS failures. I believe they share the same root as point 1 rather than being fixture bugs: the tests hand one temp-directory spelling to the child they spawn and compute the socket from the same unresolved string themselves, so the child daemon (which resolves through engineWorkspace) listened one key away from where the test attached. The identity unification removes that split for every such test, and I could not run macOS locally to verify - could you re-run make test-laws and the race run at this SHA? If any failure survives, it is a genuine fixture mismatch and I will fix those files separately.

Also added the typed /project regression the review asked for (internal/tui3). Builds, gofmt, GOOS=linux vet and the touched suites pass here; the full cmd/codeaf suite still defers to Linux CI for the same Windows limitations stated in the PR description.

A second pass over the identity question before you re-run the suites, and it caught two doors the first round left split - both now resolved at ac09e71.

1. The surface's own project key. v3Workspace minted the session bucket and the tools root from whatever spelling the terminal walked in with, so on the in-process doors (--once, --no-host, the fallback road) one folder reached through a symlink was still a second project beside the same folder named by its resolved path - the exact "two histories" complaint of workspace: a folder reached through a symlink becomes two projects and two engines #1761, one layer up. The answer now resolves at that one mint, which also keeps the projects panel and the drafts keys on one spelling, since everything downstream reads the workspace from here.

2. Memory's path fallback. gitidentity.ProjectKey's doc calls its fallback "the canonical path's hash", but filepath.Abs canonicalizes nothing about links - a non-git folder behind a symlink keyed two memory projects. The fallback now resolves, matching what the doc already promised.

Both carry regressions that fail on the previous head and pass here, and the changelog entry now names every door that mints a key instead of just the first one. tui3's full suite, the touched cmd/codeaf suites, gofmt and the changelog check are green here; the Windows-only failures this machine shows are the same set the base shows.

That closes every place a path becomes a key that I could find: engineWorkspace (named and default), enginehost.where, v3Workspace, gitidentity, and the /project pin. If your macOS run still surfaces a fixture mismatch, it will be a genuine one now.

Hi @ningmao-hlyz, thanks for the follow-up and the additional fixes!

I rechecked 16643c4ad. The local-dial and default-HOME fixes work, and the environment-status test now passes. Three points still need changes:

1. Preserve access to engines started by older builds.
   The new canonical host hash does not accommodate existing alias-keyed directories. In an upgrade fixture, Held() lists the old engine, but Dial() misses its live socket and Stop() returns false, nil. This also prevents --status-all, --stop-all and stale-host takeover from reaching it. Please preserve lookup and retirement of legacy hosts whose recorded workspace resolves to the same folder.

2. Preserve resumption of existing conversations.
   A spoken conversation stored in the old alias-keyed bucket no longer resumes: v3Workspace → v3ResolveSession selects the canonical bucket and creates a new journal. Please preserve the ability to resume these conversations through compatibility lookup or a targeted migration, and add an upgrade regression test. A comprehensive merge of historical buckets is not required here.

3. Fix the four remaining macOS fixture failures.
   Both hello tests in hostlatest_test.go, the empty-workspace status test in engine_stale_test.go, and the typed /project test in homefate_test.go still fail. The hello fixtures populate unresolved buckets; the status and pin expectations retain unresolved paths. Please normalize these fixtures and expectations while preserving their substantive assertions.

The upgrade reproductions and all four fixture failures fail at this head and pass on the exact base. Builds, vet, packed-manual and changelog checks passed. CI is green, but local laws and race runs still expose these fixture failures; unrelated failures were separately confirmed on dev.

All three points are addressed at d214013, four incremental commits on top of your merge.

1. Legacy hosts. A Dial that misses the canonical key now looks for host directories whose recorded workspace (the place file) resolves to the same folder, so Held's answer and the socket the doors dial are one fact again: --status, --stop, --status-all, --stop-all and the takeover rule all reach an engine the upgrade did not start, and the canonical dial error is what the caller still sees when nothing anywhere answers, so DialStartingHost's retry semantics do not move. Regression: a legacy directory keyed by the raw spelling with a live socket is met by a dial from the resolved folder.

2. Legacy conversations. When the canonical bucket holds nothing spoken, the newest folder in another bucket whose meta.workspace citation resolves to this folder resumes where it lives - no migration, no merge; the canonical key takes over from there. The same lookup backs the engine's hello key, so a plain hello joins the held conversation instead of booting a second agent onto its journal. Upgrade regression covers both readings, resumption and bucket.

3. The four fixtures. The two hello fixtures now populate the bucket the current build writes and stand on the resolved spelling; the empty-workspace status expectation and the typed /project pin expectation follow the same resolution. Their substantive assertions are unchanged - the hello-key-to-boot agreement, the none-sentence shape, the pin-lands-and-says-nothing behavior.

Verification here: both new regressions fail on your merge and pass at this head; the full enginehost, tui3 and cmd/codeaf failure sets are byte-identical to your merge's on this machine apart from the four fixtures this commit fixes and one known-flaky walker test; builds, gofmt, GOOS=linux vet and the changelog check are green. The changelog entry now also states the upgrade road, since a session reading "every key resolves" would otherwise not know the old records stay readable.

@ningmao-hlyz thanks for working through two rounds on this. Since nobody had re-reviewed after your last push, I've taken it over. I verified each point and pushed two fixes on top of your branch (no history rewritten).

@ZeroPoint95, all three of your points from the 14th:

1. Engines started by older builds. I rebuilt your upgrade fixture: an alias-keyed host dir with a live socket and a real flock. Held, Dial, Stop, --status, --status-all, --stop-all and idle/busy takeover all reach it from both spellings (10 door × spelling cases), and the built binary passes the same check. That turned up one more gap. Once the old socket closed, retirement only checked the new canonical lock, so it could report success while the old engine was still holding its lock and flushing journals. Retirement now waits for the legacy lock too (73262a5). The test fails on the previous head and passes now.
2. Existing conversations. An old alias-bucket conversation resumes in place through v3Workspace → v3ResolveSession. One edge case remained: if an empty canonical conversation existed, hello picked it while boot resumed the spoken legacy one, and two real socket hellos booted two agents onto the same journal. Hello now uses the same spoken-history priority as boot (58b3a98), and the regression shows one boot with two connections. Canonical spoken history still wins, and explicit sessions are unchanged.
3. macOS fixtures. Running with TMPDIR and HOME both pointed through symlinks (the /var → /private/var shape), both hostlatest hello tests, the empty-workspace status test and the typed /project test pass, with their assertions intact. The old versions of those fixtures reproduce your four failures in the same setup.

I also merged current dev. The PR gate passes on Go 1.26.5: build, vet, fmt, packed manual, changelog, laws, carried help and belt pages, plus the codeaf / rest / tui3 legs. The only noise was a TempDir cleanup flake in an unrelated shell subtest, which passes on retry and on dev. On the security side, the compatibility lookup only matches a recorded workspace whose EvalSymlinks equals the requested folder. It skips symlinked state dirs, and foreign, missing or looping citations never match. A Dial miss scans the host dirs linearly, which is fine for normal inventories; I'd only index it if someone accumulates hundreds.

Status update: I'm holding this one and moving it back to draft. Neither the original head nor the current head is safe to merge.

The fix itself is right: a folder reached through a symlink should be one workspace. The hard part is the upgrade. Two independent reviews found that changing the key with nothing else hides data existing users already have:

• path-owned project memories drop out of the project's scope,
• owned conversations under a symlinked HOME stop resuming,
• saved unsent drafts aren't found,
• a starting legacy engine doesn't block a second engine on the same folder.

I pushed a round (79b8171..de11a6b) that reads old keys as aliases when a recorded citation resolves to the same folder today. A third review found that approach is unsafe too, because a symlink can be repointed. With current -> A retargeted to B, opening B by its plain path pulls in A's historical memories, including correct and forget on them. It also restores A's unsent draft into B and refuses to start B's engine while A's is running. Separately, the CLI normalizes the workspace before taking the lock, so the raw key never gets locked in the window before a legacy daemon starts listening.

This needs a decision before more code: old keys can only be trusted if the project that owned them is recorded durably. The options I see:

1. Durable association. When a host, conversation, memory owner or draft is created, record the physical target (or a stable project ID) next to it. Treat an old key as an alias only when that recorded target matches.
2. One-time migration. At first launch after upgrade, re-own path-keyed memories, drafts and buckets whose recorded workspace resolves to the current folder, and record that the migration ran. Never re-resolve later.
3. Narrow scope. Canonicalize only the engine host key, which is what workspace: a folder reached through a symlink becomes two projects and two engines #1761's duplicate engines are about, and leave conversation, memory and draft keys alone for now.

@ZeroPoint95, which direction do you want? The reproductions for every finding above are written as Go tests, and I'll attach them to whichever route you choose.